1. Field of the Invention
This invention relates in general to a dynamic channel assignment method and system, and in particular, to a method and system for resolving a dynamic channel assignment conflict in AAL2 (ATM Adaptive Layer 2) Negotiation Procedures (ANP).
2. Description of Related Art
ATM has been selected as a world standard for broadband ISDN in network communication systems. ATM systems have been implemented on a global basis and developed in a rapid growth. ATM technology is destined to play a major role in both public and private broadband networks. AAL2 is one of the four types of AAL (ATM Adaptive Layer) protocols which have been recommended by CCITT, namely AAL1, AAL2, AAL3/4 and AAL5. In general, the layer services provided by AAL1 are constant bit rate (CBR) services which require information to be transferred between source and destination at a constant bit rate. AAL2 offers a transfer of information with a variable bit rate. In addition, timing information is transferred between source and destination. Since the source is generating a variable bit rate, it is possible that cells are not completely filled and that filling level varies from cell to cell. AAL3/4 is used for transfer of data which is sensitive to loss, but not sensitive to delay. AAL3/4 protocol may be used for connection oriented as well as for connectionless data communication. AAL3/4 itself does not perform all functions required by a connectionless service, since functions like routing and network addressing are performed on the network layer. AAL5 is designed to offer a service with less overhead and better error detection below the CPCS layer.
In a AAL2 protocol, AAL2 Negotiation Procedure (ANP) is a ITU-T recommendation for establishing peer-to-peer AAL2 channels on a single ATM connection, which is introduced in BISDN ATM Adaptation Layer 2 specification--(Annex C Dynamic allocation of AAL type 2 channels) published as a draft recommendation I.363.2 (Madrid, November 1996), approved in September 1997 (hereinafter "Recommendation"). The framework, protocol, and associated procedures are introduced to support a dynamic allocation of AAL type 2 channels. In the recommendation, there is a specific need to enable dynamic allocation of AAL type 2 channels which would allow, assign and remove (make unassigned) AAL2 channels according to the need of AAL2 connectivity as requested by an AAL2 user. The function providing a dynamic allocation of AAL2 channels is often called AAL2 Negotiation Procedures (ANP) and is carried out by an AAL2 layer management entity at each side of an AAL2 link or channel. The AAL2 layer management entity uses the services provided by the AAL2 entities for the purpose of transmitting and receiving messages defined for ANP. These messages are communicated between two peer AAL2 management entities over an AAL2 link or channel. To simplify the description, the peer AAL2 layer management entity is below referred to as AAL2 peer entity or just peer entity.
During the ANP, a Channel IDentifier (CID) is associated between peer-to-peer AAL2 entities for each connection request whereby voice or other signal packets from different users are multiplexed and demultiplexed using the CID on a single ATM connection. Generally, the size of a CID field is 8 bits, and a maximum of 256 simultaneous connections (248 of which are generally available for users and 8 of which are generally for system management use) can be supported on a single ATM connection at any given time. According to the Recommendation, during ANP, the state of the CID varies among "Unassigned", "Assignment.sub.-- initiated", "Assigned", and "Removal.sub.-- initiated" states. At any given time, a particular CID is in one of the above listed states. Further according to the Recommendation, the negotiation procedure between the peer-to-peer entities is carried out using predefined messages, such as "Assignment.sub.-- request", "Assignment.sub.-- confirm", "Assignment.sub.-- denied", "Removal.sub.-- request", "Removal.sub.-- confirm", "Status.sub.-- pool", and "Status.sub.-- response".
The existing AAL2 negotiation procedure is generally shown in FIG. 1. FIG. 1 shows a message sequence chart which describes the ANP between local and remote peer entities in details. The message sequence starts from the left top side at the local peer entity. Upon receiving a connection request from a user, the local peer entity chooses a Channel Identification (CID) among the channels which are in "unassigned" state from an ANP memory (e.g. represented by a table) at the local peer entity. The state of the chosen CID is then changed to "Assignment.sub.-- initiated", and an "Assignment.sub.-- request" message is sent to a remote peer entity on the right side. The "Assignment.sub.-- request" message may be sent to the remote peer entity on a dedicated AAL2 channel or link. Meanwhile, the local peer entity starts a T.sub.assign timer to set a maximum limit on the waiting time to receive a confirm or denial message from the remote peer entity. Once the remote peer entity received the "Assignment.sub.-- request", the remote peer entity verifies the state of the requested CID in its own ANP memory (e.g. represented by a table) associated with the remote peer entity. If the requested CID is in an "unassigned" state, then the CID is assigned to the requester, i.e. the local peer entity. Meanwhile, an "Assignment.sub.-- confirm" message as a reply message is returned to the requested local peer entity. If the CID request cannot be satisfied for reasons such as the CID assigned already state, CID being in "Assigmnent.sub.-- initiated" state, or CID being in "Removal.sub.-- initiated" state, the remote peer entity then sends "Assignment.sub.-- denied" as a reply message to the local peer entity. Thereafter, the local peer entity either completes the channel assignment or releases the "Assignment.sub.-- initiated" channel at the local peer entity based on the reply message from the remote peer entity.
Generally, the CIDs available for each AAL2 channel are limited to 256 simultaneous connections (248 of which are generally available for users and 8 of which are generally for system management use), and the peer entities are symmetrical in their functionality regarding channel assignment requests. In existing systems, there is no provision for one peer entity to find out the status of its requested CID at a remote peer entity. Due to this reason, if both local and remote peer entities receive channel assignment requests asynchronously and the same CID is chosen for respective channel assignment request at each peer entity, a conflict of using the same CID may occur. For example, before receiving an "Assignment.sub.-- request" message from the local peer entity, the remote peer entity may have received a channel assignment itself from another user requesting the same CID. Since the remote peer entity has not received the "Assignment.sub.-- request" from the local peer entity, and if the same CID chosen by the local peer entity is also available by the remote peer entity, i.e. the chosen CID having an "unassigned" status in the ANP memory table associated with the remote peer entity, the remote peer entity may assign the same CID to the other user channel upon the channel assignment request. Meanwhile, the remote peer entity sends an "Assignment.sub.-- request" message to the local peer entity and changes the status of the CID in its ANP memory table to "Assignmnent.sub.-- initiated". Afterwards, the remote peer entity receives the "Assignent.sub.-- request" from the local peer entity and checks the status of the requested CID in its ANP memory table. Since the status of the CID had been changed to "Assignment.sub.-- initiated", i.e. not in an "unassigned" state, the remote peer entity denies this CID request and sends an "Assignment.sub.-- denied" message to the local peer entity. Similarly, when the "Assignment.sub.-- request" sent by the remote peer entity reaches the local peer entity, the local peer entity checks its own ANP memory table for the status of the requested CID by the remote peer entity and finds that the status of the CID is "Assignment.sub.-- initiated" because this is the same CID that the local peer entity had requested itself. Accordingly, the local peer entity sends an "Assignment.sub.-- denied" message to the remote peer entity. Therefore, the conflict CID assignment results in both requests failing for the simple reason that they try to assign the same CID for two different requests on a single ATM connection. This causes tremendous delays for the channel connection. There was a scheme proposed to solve the problem whereby both peer entities would time out randomly after collision and retry the ANP. The main drawback of this scheme is that none of the channel assignments succeed, and additional delays are introduced by these random timers.
It can be seen that there is a need for a method and system to resolve the above-mentioned dynamic channel assignment conflict in AAL2 Negotiation Procedures.
It can also be seen that there is a need for a method and system to cause at least one of the conflicted channel assignments to succeed in a channel assignment without additional delays in the AAL2 Negotiation Procedures.